FIG. 1 shows a cellular communication system with a serving node 101 that serves a user equipment (UE) 103 located within the serving node's geographical area of service, called a cell 105. Depending on the system, the serving node 101 may e.g. be a base station, a Node B, or an evolved Node B (eNodeB or eNB). Hereinafter, the serving node 101 will be referred to as an eNB in the non-limiting example of a long term evolution (LTE) system. Communication is bidirectional between the eNB 101 and the UE 103. Communications from the eNB 101 to the UE 103 are referred to as taking place in a downlink direction, whereas communications from the UE 103 to the eNB 101 are referred to as taking place in an uplink direction.
Relay nodes may also be used in a wireless communications system. FIG. 2 illustrates a relay node (RN) 204 with a service area or cell 207, the RN 204 communicating with a donor eNB (DeNB) 202 with a service area or cell 206, and one or several UEs 203 located within the RN's cell 207. Transmissions between UE 203 and RN 204 are done over a radio interface denoted Uu, which is the same as for regular eNB to UE communication, so from a UE perspective the RN appears as a regular eNB. Transmissions between the RN 204 and the DeNB 202 are made over a radio interface denoted Un, which reuses much of the functionality of the Uu interface. This means that the DeNB 202 handles the RN 204 as a UE, using similar protocols as when communicating with a UE with some additions.
To function as an eNB in an LTE system, the RN 304 has an S1 interface setup towards the core network with the mobility management entity (MME) and/or service gateway (SGW) 308, which is proxied in the DeNB 302. The RN 304 may also have an X2 interface setup towards other eNBs 301, in which case the X2 interface is proxied in the DeNB 302. The architecture is shown in FIG. 3. The eNBs 301, the DeNBs 302, and the RN 304 are all part of the evolved universal terrestrial radio access network (E-UTRAN) 300, which is the radio network of the LTE system.
The 3GPP LTE Rel-10 work item description for a relay or RN includes the following characteristics. First, a RN control cells 207 (see illustration in FIG. 2), each of which appears to a UE as a separate cell distinct from the DeNB cell 206. Second, those RN controlled cells have their own Physical Cell IDs as defined in LTE Rel-8, and the RN transmits its own synchronization channels, and reference symbols. Third, the UE receives scheduling information and hybrid automatic repeat request (HARQ) feedback directly from the RN and sends its control channel information such as scheduling requests (SR), channel quality index (CQI), and acknowledgements (ACK) to the RN. Fourth, there should preferably not be any UE impact from the RN functionality so that legacy LTE UEs can be served by the RN cell 207.
It is desirable to support integrity protection of RN signaling and/or data between the RN and DeNB. One option is to implement this integrity protection in the packet data convergence protocol (PDCP) layer described in the 3GPP specifications as a relay-specific functionality in the PDCP layer. In such a case, the setup and configuration of the integrity protection will be done by the RRC protocol. The enabling and disabling of PDCP integrity protection—sometimes also referred to as activation and disabling of integrity protection—may be made per data radio bearer (DRB), meaning that not all DRBs would necessarily be configured to use integrity protection at a given time.
Integrity protection in PDCP may use a unique sequence number (SN) as input to the integrity protection algorithm for every, packet that is protected. This makes the integrity verification code different even for identical packets sent at different times on the same DRB as they have different SN. The complete SN used as input for integrity protection, such as a COUNT value, may not be transmitted with every packet in order to avoid unnecessary overhead. Instead, only a part of the least significant bits of this SN value—typically 7 or 12 bits which are called a PDCP SN—are transmitted in each packet. The transmitter and receiver then implicitly keep track of the remaining bits of the complete sequence number, i.e. the 25 or 20 bits that are called overflow counter or hyper frame number. This requires that the receiver increments the overflow counter every time the PDCP SN wraps around, e.g., goes from a count value 1111111→0000000.
In prior art it is proposed to support enabling of integrity protection at DRB setup. However, the proposal only allows the possibility to change the integrity protection, i.e. enable or disable the integrity protection, for an ongoing bearer at a handover. Changing the integrity protection of a DRB during normal operation is deemed too complex since it is difficult to coordinate the change of integrity protection with the ongoing traffic on the DRB, e.g., due to re-transmissions, which may lead to that some packets will be protected and some will not. One concern is that this may make it difficult for the receiver to know if integrity protection has been applied to a given packet or not.
According to the proposal, it is thus only possible to enable or disable the integrity protection at initial DRB setup, at handover, or by releasing the DRB and setting up a new DRB to carry the traffic. The new bearer may be configured with or without integrity protection depending on what is desired, independently of the configuration of the previous DRB. However, releasing and setting up a new bearer is a complex procedure which also introduces a delay. Furthermore, there is no support for lossless and duplicate-free data delivery since packets related to the old DRB, which may have been transmitted by the transmitter but so far not received by the receiver, will be discarded by the radio protocols when the old DRB is released.
A possible solution to the problem of loosing packets when releasing and setting up a new DRB, is to trigger an intra-cell handover to enable or disable integrity protection for an ongoing DRB. However, performing an intra-cell handover only for the sake of enabling or disabling the integrity protection of one or more DRBs causes unnecessary data transfer interruption which introduces delays, as well as unnecessary load on the random access channel since a random access procedure is always part of a handover. Furthermore, an intra-cell handover is an unnecessarily complex solution.
Another possible way to support enabling or disabling of integrity protection of a DRB during normal operation in prior art is to include an indication in the PDCP header indicating if integrity protection is applied to a given packet. This however introduces additional overhead in the PDCP header and could potentially be abused by an “attacker”, which may manipulate a packet which is integrity-protected by changing the indication in the PDCP header to say that it is not protected.